1. Field of the Invention
This invention relates generally to system and method for software development. More particularly, this invention is related to systems and methods for making changes to software programs.
2. Description of the Prior Art
Software development is facing ever increasing requirements of changes in response to changing business and application environments. Providing physical related help like change management system, and process related help like agile development methodologies is not enough since software is composed of logically related entities. Software professionals suffered and companies paid high price for this since existing programming paradigms especially object-oriented programming don't have solution built in for change. In fact object-oriented programming showed incapable of dealing with change efficiently as analyzed below.
Specifically, FIG. 1 illustrates an example of traditional process of creating or modifying and building a program. To create or modify a software program, a programmer interacts with a computer through an input device 102; a source program 104 is then created. After the source program 102 is created, it's sent to a compiler microprocessor 106 for compilation, which results in binary output 108. The binary output 108 is then sent to build microprocessor 110, and the output of 110 is then saved to a storage system 112. Now the program can be copied to any computer or microprocessor for execution. In order to change the software program, according to the conventional processes as now commonly practiced, the programmers have to go through the entire sequence of processes again. However, after many rounds of changes, it is usually unavoidable that the program tends to become bigger with more added applications and improved features. In the meantime, the program becomes more complicated while many modules are interdependent and inter-tangled. For these reasons, the cost of even changing one or few lines of the source code can become very high.
Currently there is no general purpose programming solution or solution at language level in dealing with software changes. There were some efforts towards this problem like design patterns which provides solution for varying part of program for some special cases, frameworks like Struts, Hibernate, which handle some application logic using configuration. These solutions focus on some special cases and can not be scaled for complex applications. The following give some reasons that a general purpose solution using one object-oriented programming language would be almost impossible.
1). Object-oriented program is not cost efficient for change. Object-oriented program tends to use good design to reduce the impact and the number of changes. As software programs are facing more and more changes, the efficient way to deal with change is not to reduce the number of changes, but to reduce the cost of single changes. And we have to predict and treat differently for program areas where changes will most likely to happen since some areas of program may have much bigger chance and higher number of changes than other areas. This is almost impossible to achieve in object-oriented programming which sticks to the principle of treating everything as object, simply and equally.2). Object-oriented program tends to be bloated due to flexibility-stability dilemma. To deal with change, software program need be stable enough to not collapse on its own weight, and be flexible enough to accommodate frequent changes easily. But stability and flexibility often apply contradictory constraints to one single language, so trade-off must be made in designing language features. This often results in bloated object-oriented program since too many objects are crafted to satisfy the stability requirements or flexibility requirements. Fat programs create more problems for change than lean programs.3). Object-oriented program can not provide bottom up solution for change. A bottom up solution for software change has tremendous cost advantage over case by case solution like design patterns. Unfortunately, class as a program unit in many object-oriented languages is never designed for such purpose like dealing with change. We can see that the dependency code of a class on some component often spread into different places of the class, which adds difficulty to change dependency in response to change in depended component.4). Object-oriented program is not scalable for change. To be scalable for change means that the cost of change on a program with multiple components, like 20 components, should not be significantly greater than the multiple times, like 20 times, of the cost of change on program with one component. This is usually not true for object-oriented programs since components of a program are logically related and the relations can grow much faster than components, even uncontrollable, and often result in unexpected cost of change. To be scalable for change, the relations and interactions between components should be well managed. Unfortunately there are no such relation and interaction management in object-oriented programming.
For these four reasons, the object-oriented programming as now commonly applied in software programs has fundamental weakness in managing and processing software changes. This often results in high cost and low productivity when dealing with software changes.
Therefore, an urgent need still exists for those involved in software program development and the management of software changes to structure and develop the software programs by taking into account of the needs for software changes with new layer structures while integrated with suitable languages for software changes such that the above discussed limitations and difficulties can be resolved.